For reducing risks to humans or the environment, especially in automated systems, safety functions are realized. Simple examples here are shutting down a machine after pressing an emergency-off button or stopping a robot when a person walks into the safety zone of the robot and in this way, e.g., breaks a light barrier or is detected by a light screen monitoring the safety zone of the robot or when a monitored access door opens. In the case of especially safety-critical processes, it could also be necessary to shut down large parts of a complex system or even the entire system if certain safety functions are activated.
For this purpose, fail-safe automation systems are used. In general, on one hand, fail-safe automation systems realize the actual safety function, such as, e.g., emergency-off switching, two-hand switching, operating-mode selection switching, etc.; on the other hand, fail-safe automation systems comprise fault-detecting and fault-correcting measures, e.g., according to mechanisms defined in standards (e.g., according to IEC 61508, ISO 13849, etc.). These mechanisms are known in principle to a person skilled in the art.
In known systems, communication systems that connect decentralized I/O devices and controllers are used depending on the extent of the systems and the degree of automation. For the transport of safety-related data, these networks are supported by secure network protocols. The secure data is here transmitted by means of parallel, secure signal wiring or transmitted in an integrated way by means of the communications system.
In the case of integrated transmission, the signal flow being used typically starts from a central safety technology unit into which the secure input signals are transported to the secure controller, processed there (secure application), and then transported to the corresponding actuators. Errors could now occur, e.g., in the hardware and firmware of the automation devices, in the infrastructure components of the networks (e.g., fieldbuses, Ethernet, etc.), and during the data transmission due to external influences, such as, e.g., EMC interference.
For example, in DE 103 53 950 A1, a control system is described in which the control unit for controlling the safety-critical processes is connected in a fieldbus-independent way, e.g., to a multi-port memory interface of the bus master.
In automation technology, there are currently two trends. On one hand, there is the decentralization of the control function and, on the other hand, there is an integration of safety technology into the control and network technology. In the case of the decentralization of the control function, this is typically moved farther into the output level. Thus, e.g., in drives, the (unsecured) control function is integrated to a limited extent.
With the integration of the safety technology in controllers and networks, strict dependencies are generated in the application process. These dependencies lead to more complex planning and programming of the systems. This stands in undesired contrast to the aspect of simplification of the safety technology with respect to handling in all phases of the life cycle in the automation technology. On one hand, this leads to slow acceptance in the transition of the conventional, hard-wired safety technology on the basis of the safety relay and, on the other hand, to error-prone use and scarce availability of the system due to so-called error triggers of the safety function.
In the sense of the simple handling and modularization capability of fail-safe automation systems, the entire safety function of a system is divided into small, manageable, locally definable, and easily verifiable modules. This corresponds to the approach of persons entrusted today with safety technology in the case of system automation. In addition, in this way, system modifications and system expansions are easily possible, without already verified system parts having to be verified again. In addition, the modularization and separation of the safety function from standard functions corresponds to the requirements of current safety standards.
Another advantage for the user is given in the possibility of constructing the decentralized safety modules in a network-independent and controller-independent way. In this way, they are independent of a specific control provider. This means that they can remain if the standard controller and/or the network must be changed—due to non-safety-relevant requirements of the target market—in the case of the safety technology being used and the verified safety modules.
Despite the possible division and decentralization of locally defined safety functions, however, system-wide safety functions are also to be encountered. Thus, e.g., the triggering of a safety function in a cell should also have effects, such as stopping movements that could cause danger in the adjacent cells.
For guaranteeing such system-wide safety functions, the decentralized safety modules are either coordinated in a fail-safe way by a higher-level central safety controller or have the ability to communicate with each other in a fail-safe way. In contrast to the original goal of simplification, both approaches lead to greater complexity in the network configuration.